比利时专利BE1022510B1 Establish a data transfer connection

专利PDF首页>>比利时专利

专利附录

专利说明

权利要求

类似技术

同族专利

引用文献

法律状态

优先权

专利摘要:
A data transfer connection (301) between a device (101, 105) and another device (102) can be established using a basic protocol with multipath extension allowing the transfer connection. data to use several different paths (304, 305) in parallel.
公开号:BE1022510B1
申请号:E2014/0846
申请日:2014-12-09
公开日:2016-05-17
发明作者:Gregory Detal；Olivier Bonaventure；Christoph Paasch
申请人:Université Catholique de Louvain；
IPC主号:

专利说明:

Establishing a Data Transfer Connection FIELD OF THE INVENTION
One aspect of the invention relates to a method of establishing a data transfer connection between a device and another device using a base protocol with an extension for enhanced data transfer. The data transfer connection can be established through a communication network, such as the Internet. The basic communication protocol may be, for example, a protocol entitled Transmission Control Protocol (in French, transmission control protocol), commonly referred to as TCP. The extension may be, for example, a multipath extension of TCP, commonly referred to as MPTCP. Other aspects of the invention relate to a computer program and a processor.
HISTORY OF THE INVENTION
A data transfer on the Internet usually involves the use of TCP. TCP allows packet data transfer from a source entity to a destination entity in a reliable and orderly manner. The source entity and the destination entity are at least partially identified by their respective IP addresses. IP is the acronym for Internet Protocol. Originally, TCP only allowed data transfer from a single IP address to a single other IP address. This implied that a TCP data transfer connection could only include one path. During a data transfer, the source entity could send data only through a single physical communication link. Similarly, the destination entity could receive data only through a single physical communication link. This is a restriction if at least one of these entities is connected to a communication network, such as the Internet, via a plurality of communication links. In this case, multiple paths are available to transfer the data.
An extension of TCP allows data to be transferred from a source entity to a destination entity through multiple parallel paths. Multipath extension is commonly referred to as TCP multipath, commonly referred to as MPTCP, and defined in RFC6824, incorporated by reference herein. In fact, MPTCP can split a data transfer stream into two parallel data transfer sub-streams. Each of these two substreams can be transported cleanly to the TCP protocol as if it were a data transfer in its entirety. One of the substreams can be routed on a communication channel; the other sub-stream can be routed to another communication channel. This diversity of paths can be obtained by specifying different IP addresses as the source entity, or the destination entity, or both, in both sub-flows.
However, this type of multipath data transfer requires that the source entity and the destination entity both support MPTCP. In other words, both the source entity and the destination entity must be able to manage MPTCP. If only one of the aforementioned entities is able to manage MPTCP, while the other is not, the data transfer takes place by a single path, conventionally according to the TCP protocol. In other words, each of the two entities involved in the data transfer can use only one physical communication link to receive data, or to send data, or both. There will be no multipath benefits, such as increased resistance and better throughput by paralleling multiple physical communication links.
The patent publication WO 2012/049631 discloses an edge router coupled to a subscriber terminal station which has not been updated to accommodate MPTCP. The edge router allows communications with the subscriber terminal station to fully utilize MPTCP. This is accomplished by executing an MPTCP proxy on the edge router that is coupled to the subscriber terminal station. Therefore, the subscriber terminal station ignores any use of MPTCP and performs TCP as normal. The edge router performs the required conversions between TCP and MPTCP such that packets sent from the TCP subscriber terminal station are demultiplexed into an MPTCP connection. Similarly, packets sent to the MPTCP subscriber terminal station are multiplexed by the edge router into a TCP connection.
The patent publication EP 2,538,637 describes a method for providing multi-path proxy services. A proxy server receives a TCP / IP connection request from a client device, which specifies that the client device is capable of establishing a multipath TCP / IP connection. In response, a single path TCP / IP connection is established between the proxy server and a serving node, while a multipath TCP / IP connection is established between the proxy server and the client device. The proxy server relays communications between the client device and the serving node on these respective connections.
SUMMARY OF THE INVENTION
There is a need for a solution that allows one device to effectively use an extension of a protocol when transferring data with another device, even if the other device is not able to handle the device. extension of the protocol.
In order to best meet this need, according to one aspect of the invention, there is provided a method of establishing a data transfer connection as defined in claim 1. Another aspect of the invention relates to a computer program comprising a set of instructions that allows a processor, capable of executing the set of instructions, to implement this method. Another aspect of the invention relates to a processor adapted to implement this method.
In each of these aspects, a device capable of managing the multipath extension may systematically use this extension, at least in a portion of a data transfer connection that extends between that device and an intermediate device. The device can thus systematically benefit from the diversity of the paths even if another device, with which the data transfer connection is established through the intermediate device, is not able to handle the multipath extension.
The aspects presented above can furthermore contribute to solving a problem of deploying an extension of a data transfer protocol. In particular, if a device can only use an extension when transferring data with devices that are also capable of managing the extension, it may be of little interest to have such a device capable of managing an extension. This can be especially true if there are relatively few devices that can handle an extension. This situation can be likened to the story of "the egg and the chicken". In the aspects presented above, a device capable of managing an extension can effectively use this extension when transferring data with another device even if the other device is not able to handle an extension. This can therefore be a solution to the deployment problem as described.
It should be noted that the method as defined in claim 1 differs fundamentally from that of using a periphery router as described in the aforementioned patent publication. The edge router is coupled to a specific subscriber terminal station to allow this subscriber terminal station to benefit from MPTCP. However, another subscriber terminal station, with which the data will be transferred, must fulfill at least one of the following two conditions. The other subscriber terminal station must be able to manage MPTCP. In the opposite case, an edge router must also be coupled with the other subscriber terminal station. In other words, an MPTCP data transfer is only possible if each subscriber terminal station which is not capable of managing MPTCP is coupled to an edge router as described in the aforementioned patent application. We are therefore faced with a potential deployment problem similar to that described above for edge routers.
According to another aspect of the invention, there is provided a method for generating a connection request as defined in claim 10. Another aspect of the invention relates to a computer program comprising a set of instructions that allows a processor, capable of executing the set of instructions, to implement this method. Another aspect of the invention relates to a processor adapted to implement this method.
These other aspects of the invention explicitly allow to include an intermediate device during a data transfer connection between two devices. The intermediate device may be, for example, a device specially designated from a group of devices that are interconnected with each other, as well as with the two aforementioned devices, through a communication network. The data transfer connection can be made to explicitly pass through the intermediate device, at least initially. The intermediate device may contribute to, for example, the data transfer connection becoming more reliable or faster, or both. Another advantage of the intermediate device being explicitly present during the data transfer connection lies in the fact that it can help to identify and solve a problem during the data transfer connection.
An embodiment of the invention may optionally include one or more additional features as defined in the dependent claims. Each of these additional features can contribute to at least one of the above benefits, and may offer other benefits. By way of illustration, a detailed description of some embodiments of the invention is presented with reference to the accompanying drawings.
SUMMARY DESCRIPTION OF THE DRAWINGS
FIG. 1 is a conceptual diagram that illustrates a communication infrastructure.
FIG. 2 is a flowchart illustrating a method of establishing a data transfer connection in the communication infrastructure.
FIG. 3 is a conceptual diagram that illustrates the data transfer connection that has been established in the communication infrastructure.
FIG. 4 is a conceptual diagram illustrating another data transfer connection that may have been established in the communication infrastructure.
FIG. 5 is a conceptual diagram that illustrates a destination option that may be included in an option field of a header of a connection request.
FIG. 6 is a conceptual diagram that illustrates a payload section of a connection request.
DETAILED DESCRIPTION
FIG. 1 schematically illustrates a communication infrastructure 100, which comprises several communication devices 101, 102, 103 coupled to a communication network 104. The communication network 104 may include, for example, the Internet network. The communication network 104 will hereinafter be referred to as the Internet 104 for the sake of convenience. A communication device 101 may obtain services from another communication device 102 through the Internet 104. The communication device 101, which can obtain services, will hereinafter be referred to as the client device 101. Another communication device 102, which can provide services, will hereinafter be referred to as the server device 102. The server device 102 illustrated in FIG. 1 can be any communication device among many communication devices capable of providing services over the Internet 104. The communication infrastructure 100 includes a communication device 103 which can act as an intermediary between the device client 101 and the server device 102. This communication device 103 will hereinafter be referred to as the intermediate device 103. The intermediate device 103 may be one of a group of communication devices capable of providing services to the Internet 104 In other words, the intermediate device 103 may constitute a part of a "cloud" of such devices in the communication infrastructure 100. It can be said that the intermediate device 103 is in the "cloud".
FIG. 1 shows an example in which the client device 101 is coupled to the Internet 104 via a router 105. The client device 101 and the router 105 may constitute a part of a local area network 106, which may belong, for example, to a network. society or home. The local network 106 may include other client devices, which may also be coupled to the Internet 104 via the router 105.
Several physical communication links 107, 108 couple the router 105 to the Internet 104. For example, a first physical communication link 107 coupling the router 105 to the Internet 104 may be part of a fixed telephony network. A second physical communication link 108 may be part of, for example, a mobile telephone network. There may be other physical communication links, which have not been represented for the sake of clarity and to facilitate explanation. For each different physical communication link, a dedicated communication interface may be installed between the router 105 and the concerned network, which provides the communication link.
The router 105 has different IP addresses 109, 110, IP being the acronym for Internet 104 Protocol (in French, Internet protocol). A first IP address 109 is associated with the first physical communication link 107. A second IP address 110 is associated with a second physical communication link 108. Therefore, a data transfer that specifies the first IP address 109 will pass through the first physical communication link 107. Similarly, a data transfer that specifies the second IP address 110 will pass through the second physical communication link 108. The router 105 may have other IP addresses if there are other links. physical communication.
The intermediate device 103 may have only one IP address 111 as illustrated in FIG. The intermediate device 103 may be connected to the Internet 104 via a single physical communication link 112. Similarly, the server device 102 may have only one IP address 113. The server device 102 may be connected to the Internet 104 via a single physical communication link 114. The presentation in FIG. 1 was done for the sake of clarity and to facilitate the explanation. The intermediate device 103 may have different IP addresses, as well as several physical communication links that provide connections with the Internet 104. The same is true for the server device 102.
A transfer of data on the Internet 104 generally involves the use of a protocol entitled Transmission Control Protocol (in French, transmission control protocol), commonly referred to as TCP. TCP allows packet data transfer from a source entity to a destination entity in a reliable and orderly manner. The source entity and the destination entity are at least partially identified by their respective IP addresses. Originally, TCP only allowed data transfer from a single IP address to a single other IP address. This implied that a TCP data transfer connection could only include one path. During a data transfer, the source entity could send data only through a single physical communication link. Similarly, the destination entity could receive data only through a single physical communication link. This is a restriction if at least one of these entities is connected to a communication network, such as the Internet, via a plurality of communication links. In this case, multiple paths are available to transfer the data.
An extension of TCP allows data to be transferred from a source entity to a destination entity through multiple parallel paths. Multipath extension is commonly referred to as TCP multipath, commonly referred to as MPTCP, and defined in RFC6824, incorporated by reference herein. In fact, MPTCP can split a data transfer stream into two parallel data transfer sub-streams. Each of these two substreams can be transported cleanly to the TCP protocol as if it were a data transfer in its entirety. One of the substreams can be routed on a communication channel; the other sub-stream can be routed to another communication channel. This diversity of paths can be obtained by specifying different IP addresses as the source entity, or the destination entity, or both, in both sub-flows.
However, this type of multipath data transfer requires that the source entity and the destination entity both support MPTCP. In other words, both the source entity and the destination entity must be able to manage MPTCP. If only one of the aforementioned entities is able to manage MPTCP, while the other is not, the data transfer takes place by a single path, conventionally according to the TCP protocol. In other words, each of the two entities involved in the data transfer can use only one physical communication link to receive data, or to send data, or both. There will be no multipath benefits, such as increased resistance and better throughput by paralleling multiple physical communication links.
Referring to FIG. 1, the router 105 is able to manage MPTCP. The client device 101 need not be able to manage MPTCP. It can be considered that the router 105 has been inserted between the client device 101 and the Internet 104 in order to allow the client device 101 to benefit from the different physical communication links 107, 108 with the Internet 104.
However, it is not necessary for the server device 102 to be able to manage MPTCP; the server device 102 may only be able to communicate according to a basic version of TCP, allowing only one-way communication. If the client device 101 establishes a data transfer connection with the server device 102 in a conventional manner, the client device 101 will not benefit from the different physical communication links 107, 108 provided by the router 105 in order to access the Internet. 104.
We are therefore faced with a potential deployment problem for MPTCP. It is relatively unattractive to have a communication device capable of managing MPTCP if there are relatively few other communication devices worthy of interest capable of managing MPTCP. In such a case, there is little incentive to upgrade a communication device to make it capable of managing MPTCP. There is also little incentive to develop new communication devices capable of managing MPTCP. This situation can be likened to the story of "the egg and the chicken", and thus lead to a relatively slow deployment of MPTCP.
The intermediate device 103 can provide a solution. The intermediate device 103 is capable of managing MPTCP. This intermediate device 103 can function as an MPTCP / TCP converter during data transfers between the router 105 and the server device 102. Such a data transfer is in fact organized as a concatenation of two data transfer parts: a part of data transfer according to the MPTCP protocol between the router 105 and the intermediate device 103, and another portion of data transfer according to the TCP protocol between the intermediate device 103 and the server device 102.
In this scheme, the client device 101 can at least benefit from the different physical communication links 107, 108 provided by the router 105 in order to access the Internet 104. If one of these links fails, the data transfer can continue on another route. An established connection is not lost; the connection is more resistant. In addition, the data transfer can be performed at a higher rate by the paralleling of the two communication links. An established connection can be faster, and offer a higher throughput.
FIG. 2 schematically illustrates a method of establishing a data transfer connection between the client device 101 and the server device 102 in the communication infrastructure 100 illustrated in FIG. The method explains by way of example how a data transfer connection between a device capable of managing MPTCP and a device incapable of managing MPTCP can be organized by including a concatenation of the two following portions of data transfer connection. First, a MPTCP portion of a data transfer connection between the device capable of managing MPTCP and the intermediate device 103. Second, a TCP portion of a data transfer connection between the intermediate device 103 and the device unable to manage MPTCP.
The method comprises a series of steps 201 to 210, which involve the client device 101, the router 105, the intermediate device 103 and the server device 102. FIG. 2 is therefore divided vertically into several columns. A left-most column illustrates several steps performed by the client device 101. A left-center column illustrates several steps performed by the router 105. A right-center column illustrates several steps performed by the intermediate device 103. far right illustrates several steps performed by the server device 102.
The far left column of FIG. 2 may be considered as a flowchart of a computer program, in other words, a set of instructions, allowing the client device 101 to perform several operations described below with reference to FIG. 2. Similarly, the left center column, the center right column, and the far right column of FIG. 2 may be considered as flowcharts of respective computer programs, allowing the router 105, the intermediate device 103, and the server device 102, respectively, to perform several operations described hereinafter with reference to FIG. 2. The set of instructions concerning the intermediate device 103 may advantageously be in the form of a kernel module in an operating system which operates on the intermediate device 103.
During a connection request transmission step 201, the client device 101 sends a connection request 211 which is directed to the server device 102. The connection request 211 comprises a TCP segment with a "SYN" flag which is set, as specified in TCP. Such a TCP segment will be referred to hereafter as the SYN segment. The SYN segment has a header that identifies a source port and a destination port, as well as other types of information as specified in TCP. The SYN segment may be encapsulated in a packet that specifies the IP address of the client device 101 in a source address field, and the IP address 113 of the server device 102 in a destination address field. Such a packet may be, for example, an IP packet or a UDP packet, where UDP is the acronym for User Datagram Protocol.
During a connection request substitution step 202, the router 105 intercepts the connection request 211 that has been sent by the client device 101. The router 105 then performs a series of operations, which will be described below. The router 105 can also perform this series of operations when intercepting any other connection request.
Instead of routing the connection request 211 to the IP address specified in the destination address field, which corresponds to the server device 102 in this example, the router 105 replaces the connection request with an indirect connection request 212 which is directed to the intermediate device 103. The format of the indirect connection request is similar to that of the connection request 211. In other words, the connection request also includes a SYN segment encapsulated in an IP packet, which has a destination address field and a source address field.
In order to direct the indirect connection request 212 to the intermediate device 103, the router 105 places the IP address 111 of the intermediate device 103 in the destination address field of this message. In fact, the router 105 can systematically overwrite the IP address in the destination address field of an intercepted connection request, which corresponds to the IP address 113 of the server device 102 in this example, by the IP address 111 of the intermediate device 103. The router 105 places one of its two IP addresses in the source address field of the indirect connection request 212. In this example, it is assumed that the router 105 places its first IP address 109 in the source address field of the indirect connection request 212.
The router 105 places the IP address specified in the destination address field of the connection request in a specific field of the indirect connection request 212. The specific field is a field other than the destination address field. The router 105 may also place in this specific field the destination port identified in the SYN segment header in the connection request that was intercepted by the router 105. In this example, the specific field in the indirect connection request 212 thus includes the IP address 113 of the server device 102 as well as the destination port.
It is known from the intermediate device 103 that the specific field includes an indication of a target entity with which the IP address specified in the source address field seeks to establish a data transfer connection. The specific field that includes the indication of the target entity may be located in the SYN segment of the indirect connection request 212. Specifically, the aforementioned field may be located in a SYN segment header or a load section. useful for the SYN segment. This will be more fully described below.
The router 105 includes an option named MP_CAPABLE in the SYN segment of the indirect connection request 212. This option is a bit string in the SYN segments that indicates that the IP address specified in the source address field is capable of handling MPTCP.
The router 105 may create a session responsible for performing a relay role in a data transfer connection that is established between the two following entities. First, an entity whose IP address is specified in the source address field of the connection request that was intercepted by the router 105. Second, the intermediate device 103 to which the indirect connection request 212 is directed. Therefore, the session created in this example by the intermediate device 103 relates to the data transfer connection between the client device 101 and the intermediate device 103. These entities both being capable of managing MPTCP, this data transfer connection can use multiple paths in parallel: a path via the first physical communication link 107, and another path via the second physical communication link 108 shown in FIG. 1.
During an indirect connection request processing step 203, the intermediate device 103 receives the indirect connection request 212 that has been sent by the router 105. The intermediate device 103 then performs a series of operations, which will be described here. -after. The intermediate device 103 may perform this series of operations upon receipt of any other indirect connection request 212. Such another indirect connection request 212 may have been transmitted by an entity in the communication infrastructure 100 shown in FIG. 1 other than the router 105.
The intermediate device 103 recognizes that the indirect connection request 212 includes the specific field indicating the target entity with which the data transfer connection is to be established. The intermediate device 103 retrieves the IP address from this specific field, which corresponds to the IP address 113 of the server device 102 in this example, as well as the destination port. Intermediate device 103 further recognizes the MP_CAPABLE option in the SYN segment of this message.
The intermediate device 103 may create a session responsible for performing an intermediary role in establishing a data transfer connection between the following entities. First, an entity whose IP address is specified in the source address field of the indirect connection request 212. Second, an entity whose IP address is specified in the specific field indicating the target entity. Therefore, the session created in this example by the intermediate device 103 relates to the data transfer connection between the router 105 and the server device 102.
After recognizing the MP_CAPABLE option, the intermediate device 103 seeks to determine whether the target entity, which corresponds to the server device 102 in this example, is capable or not of managing MPTCP. The intermediate device 103 can do this by performing the following steps.
During a delegated connection request step 204, the intermediate device 103 issues a delegated connection request 213 which is directed to the target entity, which corresponds to the server device 102 in this example. The format of the delegate connection request 213 is similar to that of the connection request that was issued by the client device 101. In other words, the connection request also includes a SYN segment, as defined in TCP, encapsulated in an IP packet, which has a destination address field and a source address field. The adjective "delegate" is actually only used to distinguish between this connection request, which is directed by the intermediate device 103 to the target entity, and the connection request that was originally directed by the client device 101 to the server device 102.
The intermediate device 103 includes the option MP_CAPABLE in the SYN segment of the delegated connection request 213. The intermediate device 103 places its IP address in the source address field and the IP address of the server device 102 in the field of destination address. The intermediate device 103 associates the delegated connection request 213 with the aforementioned session that has been created.
In an initial acknowledgment step 205, the server device 102 receives the delegated connection request 213 that has been issued by the intermediate device 103. The server device 102 processes this connection request as any request for connection. ordinary connection comprising a SYN segment. In fact, at least at this point, the server device 102 ignores, so to speak, the intermediate device 103 has issued the delegated connection request 213 in response to the substitution connection request that was issued by the router 105 when of the interception of the connection request of the client device 101. In other words, at this point, the server device 102 ignores the entire chain of requests. The server device 102 processes the delegated connection request 213 as an ordinary connection request according to TCP. This implies that the server device 102 can recognize the MP_CAPABLE option in the SYN segment of the delegate connection request 213.
In the initial acknowledgment step 205, the server device 102 issues an initial acknowledgment 214 which is directed to the intermediate device 103. The initial acknowledgment 214 includes a TCP segment having a flag " ACK "which is set and a sequence number field with an appropriate value, which is derived from the SYN segment received, all as specified in TCP. Such a TCP segment will hereafter be referred to as the TCP / ACK segment. The SYN / ACK segment is encapsulated in an IP packet that specifies the IP address 113 of the server device 102 in a source address field, and the IP address 111 of the intermediate device 103 in a destination address field. The server device 102 thus responds to the delegated connection request in a manner similar to any other ordinary connection request with TCP.
If the server device 102 is capable of managing MPTCP, the server device 102 includes the MP_CAPABLE option in the SYN / ACK segment of the initial acknowledgment 214. Conversely, if the server device 102 is not capable of managing MPTCP , the MP_CAPABLE option will not be included in the SYN / ACK segment of the initial acknowledgment 214. Therefore, the server device 102 indicates in the initial acknowledgment 214 whether the server device 102 is capable or not of manage MPTCP. In this example, the server device 102 is not able to manage MPTCP and therefore the SYN / ACK segment does not include the MP_CAPABLE option.
In a step of analyzing the initial acknowledgment 206, the intermediate device 103 receives the initial acknowledgment 214 that was issued by the server device 102. The intermediate device 103 associates the initial acknowledgment of receipt 214 with the session that was created by the intermediate device 103 for its role as an intermediary in the data transfer connection between the router 105 and the server device 102. The intermediate device 103 determines whether the MP_CAPABLE option is included or not. in the SYN / ACK segment. Therefore, the intermediate device 103 determines whether the server device 102 is capable or not of managing MPTCP. This will affect the intermediary role exerted by the intermediate device 103 in establishing the data transfer connection between the client device 101 and the server device 102, as will be more fully described hereinafter.
In a first subsequent acknowledgment step 207, the intermediate device 103 transmits a first subsequent acknowledgment 215 which is directed to the router 105. The format of the first subsequent acknowledgment 215 is similar to that of the initial acknowledgment 214 that was issued by the server device 102. The first subsequent acknowledgment 215 also includes a SYN / ACK segment encapsulated in an IP packet. Here, the IP packet specifies the IP address 111 of the intermediate device 103 in the source address field. The intermediate device 103 places in the destination address field the IP address that was specified in the source address field of the indirect connection request 212 associated with the relevant session. In this example, the IP address is the first IP address 109 of the router 105. Furthermore, the SYN / ACK segment of the first subsequent acknowledgment includes the MP_CAPABLE option. The intermediate device 103 thus informs the router 105 that it is also capable of managing MPTCP.
In a subsequent first acknowledgment analysis step 208, the router 105 receives the first subsequent acknowledgment 215 that has been issued by the intermediate device 103. The router 105 associates the first subsequent acknowledgment 215 with the a session that has been created by the router 105 for its relay role in the data transfer connection between the client device 101 and the intermediate device 103. The intermediate device 103 determines whether the MP_CAPABLE option is included in the SYN / ACK segment . Therefore, the data transfer connection between the router 105 and the intermediate device 103 can take multiple paths. In other words, the data transfer connection can use multiple paths: it can also use the second physical communication link 108, which connects the router 105 to the Internet 104, in parallel with the first physical communication link. 107, which participates in establishing the data transfer connection as described with reference to FIG. 2.
In a second subsequent acknowledgment step 209, the router 105 issues a second subsequent acknowledgment 216 which is directed to the client device 101. The format of this second subsequent acknowledgment 216 is similar to that of the initial acknowledgment 214 and the first subsequent acknowledgment 215. The second subsequent acknowledgment 216 also includes a SYN / ACK segment encapsulated in a packet. The router 105 places the IP address 113 of the server device 102 in the source address field, instead of placing its own IP address in the source address field. The IP address of the client device 101 is specified in the destination address field. The MP_CAPABLE option is not included in the second subsequent acknowledgment 216. This is because this option was not included in the connection request that was issued by the client device 101, and which was intercepted by the router 105.
In a subsequent second acknowledgment receiving step 210, the client device 101 receives the second subsequent acknowledgment 216 that has been issued by the router 105. The client device 101 considers this acknowledgment as having been issued by the client device 102 in response to the connection request that was issued by the client device 101. This is because the IP address 113 of the server device 102 is specified in the source address field of this acknowledgment. . In a manner of speaking, the client device 101 ignores that the data transfer connection that has been established by the server device 102 involves the router 105 and the intermediate device 103. In other words, like the device server 102, at least at this point, the client device 101 ignores, so to speak, this chain of devices during the data transfer connection with the server device 102. The router 105 and the intermediate device 103 are transparent to the device customer 101.
FIG. 3 illustrates the data transfer connection 301 between the client device 101 and the server device 102 that has been established as described above. In this example, it was considered that the server device 102 was not able to manage MPTCP, which was detected by the intermediate device 103. The intermediate device 103 thus organizes the data transfer connection between the client device 101 and the server device 102 such that the connection comprises a concatenation of two data transfer connection portions. First, a multipath data transfer connection portion 302 between the router 105 and the intermediate device 103 according to MPTCP. Secondly, a single path data transfer connection portion 303 between the intermediate device 103 and the server device 102 according to a conventional version of TCP, without the multipath extension.
FIG. 3 shows that the multipath data transfer connection portion 302 between the router 105 and the intermediate device 103 starts with an initial path 304 between the first IP address 109 of the router 105 and the IP address 111 of the intermediate device 103. This is because the router 105 has specified its first IP address 109 in the indirect connection request 212, which has been directed to the intermediate device 103. The initial path 304 thus includes the first physical communication link 107 illustrated in FIG. . This is because this communication link 107 connects the router 105 via its first IP address 109 to the Internet 104.
Since the router 105 and the intermediate device 103 are both capable of managing MPTCP, an additional path 305 may be added to the multipath data connection connection portion. This additional path 305 extends between the second IP address 110 of the router 105 and the IP address 111 of the intermediate device 103. The additional path therefore comprises the second physical communication link 108 illustrated in FIG. This is because this communication link 108 connects the router 105, via its second IP address 110, to the Internet 104. MPTCP specifies a mechanism for adding a path to a data transfer connection which has established, as described above. A path is actually added in a manner similar to that used to establish a data transfer connection as originally specified in TCP. To add a path between two devices capable of managing MPTCP, it is therefore necessary that one of the devices sends a SYN segment and the other device returns a segment SYN / ACK, these segments to include an option "MP_JOIN". This option indicates that the data transfer connection thus established must be added to a multi-path data transfer connection already established.
More specifically, in the example illustrated in FIG. 3, the additional path 305 may be added to the multipath data connection portion as follows. The router 105 issues a path adding request that is directed to the intermediate device 103. The format of the path addition request is similar to that of the connection request described above which has been issued to the router. Originally by the client device 101. In other words, the path addition request also includes a SYN segment encapsulated in an IP packet, which has a source address field and an address field. of destination. One of the specific features of the path addition request is that the SYN segment includes the aforementioned MP_JOIN option. This option includes information that associates the additional path 305 with the multipath data connection connection portion that has been established. Consequently, the MP_JOIN option makes it possible to associate the additional path 305 with the initial path 304 of this connection part. The IP packet specifies its second IP address 110 in the source address field and the IP address 111 of the intermediate device 103 in the destination address field. In this example, the second IP address 110 distinguishes between the additional path 305 and the initial path 304, which was the first IP address 109 of the router 105 as the endpoint. Upon receipt of the path adding request, the intermediate device 103 transmits a path adding acknowledgment that is redirected to the router 105. The format of this path addition acknowledgment is similar to that of the path add-in acknowledgment. acknowledgments described above, which were issued during the establishment of the data transfer connection as shown in FIG. 2. In other words, the path addition acknowledgment also includes a SYN / ACK segment encapsulated in an IP packet, which has a source address field and a destination address field. destination. The SYN segment also includes the aforementioned MP_JOIN option.
The intermediate device 103 performs TCP / MPTCP conversions during the data transfer connection between the client device 101 and the server device 102 illustrated in FIG. 3. For this purpose, the intermediate device 103 may in fact provide an MPTCP communication port and a TCP communication port. The MPTCP communication port is provided for the multipath data transfer connection portion with the router 105. The TCP communication port is provided for the single path data transfer connection portion with the server device 102.
Upon data transfer from the client device 101 to the server device 102, the MPTCP segments carrying payload data arrive at the MPTCP communication port of the intermediate device 103. An MPTCP segment may arrive via the initial path 304 or the path additional 305, if this path has been included in the multipath data connection connection part. This is because the router 105 can split a stream of TCP segments from the client device 101 into two sub-stream MPTCP segments directed to the intermediate device 103. One of the sub-streams can take the initial path 304 ; the other sub-stream may take the additional path 305. In fact, the intermediate device 103 merges these two sub-stream MPTCP segments through the MPTCP communication port.
The intermediate device 103 retrieves the payload data from the MPTCP segments that arrived on the MPTCP communication port. The intermediate device 103 then places this data in TCP segments which are directed to the server device 102 through the TCP communication port. This relaying of data may require resequencing of the segments. This is because the MPTCP segments transported in one sub-stream arrive independently of the MPTCP segments that are transported in the other sub-stream.
Relaying data from the MPTCP communication port to the TCP communication port may require additional operations at the header level. The intermediate device 103 may translate information contained in the header of a received MPTCP segment, which carries payload data, to the header of a TCP segment in which these data are placed. This mapping may require, for example, removing an option specific to MPTCP. This transposition may also require a translation of order number: the MPTCP segments may use a numbering order different from that used for TCP segments. In addition, the received MPTCP segment has a checksum. This checksum may no longer be valid if the header data is changed. The intermediate device 103 can then calculate a new checksum for the TCP segment.
Conversely, during a data transfer from the server device 102 to the client device 101, the TCP segments carrying payload data arrive at the TCP communication port of the intermediate device 103. The intermediate device 103 retrieves the payload data from from these TCP segments. The intermediate device 103 then places this data in MPTCP segments which are directed to the router 105 through the MPTCP communication port. This data relay may require a distribution between two sub-streams: a sub-stream that borrows the initial path 304 and another sub-stream that takes the additional path 305 to the router 105. This distribution may be based on an algorithm of scheduling.
FIG. 4 illustrates another data transfer connection 401 between the client device 101 and the server device 102 that can be established if the server device 102 is capable of managing MPTCP. This contrasts with the example described above, in which it was considered that the server device 102 was not able to handle MPTCP. The data transfer connection illustrated in FIG. 4 comprises a concatenation of two multipath data transfer connection portions 402, 403: a portion 402 between the router 105 and the intermediate device ^, and another connection portion 403 between the intermediate device 103 and the server device 102 In such a situation, it is not necessary to have an intermediary between the router 105 and the server device 102. The router 105 can establish a direct multipath data transfer connection with the server device 102 according to MPTCP. .
In the situation illustrated in FIG. 4, the intermediate device 103 may withdraw from the data transfer connection between the client device 101 and the server device 102. This removal may even be advantageous. In particular, in the situation illustrated in FIG. 4, MPTCP segments transferred from the router 105 to the server device 102, and vice versa, pass through the intermediate device 103. This may cause a delay and have other disadvantages. The intermediate device 103 can use the mechanisms proposed by MPTCP to retract.
For example, the intermediate device 103 may issue a TCP segment with an "ADD-ADDR" option. This TCP segment is routed to the router 105. The ADD-ADDR option specifies a new IP address for the multipath data transfer connection portion between the router 105 and the intermediate device 103. However, an IP address 113 of the server device 102 is presented as this new IP address. Upon receipt of the above TCP segment, the router 105 establishes a new data path connection with the new IP address specified in the ADD-ADDR option. The router 105 establishes this new connection as if it were an additional path to be added to the multipath data transfer connection portion between the router 105 and the intermediate device 103. This method is similar to that described above using the MP_JOIN option. Therefore, the intermediate device 103 forces the router 105 to establish a direct data transfer connection with the server device 102.
Subsequently, the intermediate device 103 may withdraw from the data path connection between the router 105 and the server device 102. The intermediate device 103 may be withdrawn in different ways. For example, the intermediate device 103 may issue a TCP segment including a "REMOVE-ADDR" option, which specifies an IP address to be removed. The intermediate device 103 directs one such TCP segment to the router 105 and another to the server device 102. On receiving the TCP segment with the REMOVE-ADDR option, the router 105 will stop using the IP address specified in this option. as a possible destination for TCP segments during the relevant data transfer connection. Also, upon receipt of the TCP segment with the REMOVE-ADDR option, the server device 102 will stop using the IP address specified in this option as a possible destination.
In another example, the intermediate device 103 may issue a TCP segment including an "MP-PRIO" option, which specifies an IP address to be used as a backup address to which a TCP sub-stream of segments can be directed. The intermediate device 103 directs one such TCP segment to the router 105 and another to the server device 102. On receiving the TCP segment with the MP-PRIO option, the router 105 will stop actively using the IP address specified in this option as a possible destination for TCP segments during the relevant data transfer connection. The IP address will be used if no other possible destination is available. Similarly, upon receipt of the TCP segment with the MP-PRIO option, the server device 102 will cease to actively use the IP address specified in this option as a possible destination.
If the MP-PRIO option is used, the router 105 and the server device 102 do not actually close their respective data path connections with the intermediate device 103. These data path connections are rather maintained in standby mode. This implies that the router 105 and the server device must continue to perform operations to maintain this backup mode, which can be a waste of resources. The MP-PRIO option may, however, be advantageous in the event of a relatively long delay before the multipath direct data connection is established between the router 105 and the server device 102 and can be effectively used for a transfer. of data. In particular, the data transfer can still continue via the intermediate device 103 during this period.
It may be advantageous to combine the use of the REMOVE-ADDR option and the MP-PRIO option to remove the intermediate device 103 from the data transfer connection between the router 105 and the server device 102. Intermediate device 103 may initially send the TCP segments with the MP-PRIO option to router 105 and server device 102 as described above. After a certain delay, which can be predefined, the intermediate device 103 can then send the TCP segments with the REMOVE-ADDR option. The aforementioned delay is preferably such that there is a high probability, or even certainty, that the multipath direct data connection between the router 105 and the server device 102 has been established. In other words, the TCP segments with the REMOVE-ADDR option are preferably sent when the intermediate device 103 is no longer needed for a data transfer between the router 105 and the server device 102.
Many aspects of the method and operations described above apply in the case where a client device 101 capable of managing MPTCP seeks to establish a data transfer connection with the server device 102 illustrated in FIG. 1. In other words, referring to FIG. 1, the client device 101, which is not capable of managing MPTCP, and the router 105, which is capable of managing MPTCP, can be replaced by a device capable of managing MPTCP without this having a great effect on what has been explained above.
A device capable of managing MPTCP can be, for example, in the form of a smart phone equipped with several communication interfaces. For example, a smart phone can have a 3G / 4G interface and a WiFi interface. The smart phone can use both interfaces during the data transfer period. The smart phone can therefore replace the client device 101 and the router 105 illustrated in FIG. 1. In this case, the 3G / 4G interface can provide the first physical communication link 107; the WiFi interface can provide the second physical communication link 108.
A client device 101 capable of managing MPTCP, which overrides the client device 101 and the router 105 illustrated in FIG. 1, can then issue an indirect connection request 212 as described above, which is directed to the intermediate device 103. In fact, the client device 101 capable of managing MPTCP can systematically issue an indirect connection request 212 when this device Client 101 attempts to establish a data transfer connection with a server device 102. In other words, the client device 101 capable of managing MPTCP can systematically involve an intermediate device 103 in establishing this data transfer connection. Therefore, the client device 101 capable of managing MPTCP can effectively benefit from several physical communication links that provide a connection to the Internet 104, even when the server device 102 is not capable of managing MPTCP. For example, the aforementioned smart phone can effectively use its two interfaces, 3G / 4G and WiFi, to perform data transfers with the server device 102 which is not able to manage MPTCP. As mentioned above, this allows for increased resistance and higher throughput, in other words, a connection that is both more reliable and faster.
Similar to what has been described above for the router 105, the client device 101 capable of managing MPTCP places one of its IP addresses in the source address field of the indirect connection request 212. The field destination address specifies the IP address 111 of the intermediate device 103. The router 105 places the IP address 113 of the server device 102 in the specific field of the indirect connection request 212 of which it is known by the intermediate device 103. it includes an indication of a target entity. This specific field may also specify the destination port in the server device 102. As mentioned above, the specific field that includes the indication of the target entity may be located in the SYN segment of the indirect connection request 212.
There are different methods for embedding in an SYN segment an indication of a target entity with which a data transfer connection is to be established. For example, this indication, which includes the IP address 113 of the server device 102 and the destination port, may be specified in a TCP options field. TCP provides that a SYN segment can include an option field of up to 320 bits, which corresponds to a maximum of 40 bytes. The options field can specify one or more options from a set of predefined option types. An option can be specified using an octet string: an octet specifying the type of the option, an octet specifying the length of the option, and one or more octets specifying the option data. TCP allows you to define an option of a particular type. It is thus possible to define a destination option that includes, as option data, the indication of the target entity with respect to its IP address and the destination port.
FIG. Figure 5 schematically illustrates a destination option 500 that may be included in a header of a SYN segment. The destination option 500 is represented by a matrix consisting of two rows and four columns. A row represents a 32-bit data word. A column represents a byte, an 8-bit string, in a row of data. The destination option 500 includes a first byte 501 indicating that this option specifies a destination. This implies that the value of the first byte 501 is reserved to indicate "destination" as the type of the option. A second byte 502 indicates that the total length of the destination option 500 is 8 bytes. A third byte and a fourth byte 503 constitute a 16-bit integer defining a destination port. The destination port can thus be defined in a manner similar to that used to define the destination port in the header of a SYN segment. Fifth to eighth bytes 504 indicate an IP address: the IP address of the destination. In this example, 32 bits are thus available to express the IP address. This implies that the IP address is of type "v4".
In principle, it is possible to specify an IP address of type "v6" in a destination option by creating the destination option long enough, that is, longer than the 8 bytes in the example described above. above with reference to FIG. 2. However, if a SYN segment includes the MP_CAPABLE option, 32 of the 40 bytes available in the options field are already in use. There are only 8 bytes available for an additional option, such as the destination option 500 described above. Therefore, if a SYN segment includes the MP_CAPABLE option, the SYN segment is constrained to specify an IPv4 address as a destination in the destination option 500 described above, which is included in the options field of the -head.
There is another method for embedding in the SYN segment an indication of the target entity with which the data transfer connection is to be established. In addition to the header, the SYN segment includes a payload section. The above indication, which includes the IP address 113 of the server device 102 and the destination port, may be specified in the payload section. In principle, there is no constraint on the version of the IP address that can be specified. In other words, an IPv6 address can be specified in the payload section of a SYN segment that includes the MP_CAPABLE option in the options field of its header.
FIG. 6 schematically illustrates a payload section 600 of a SYN segment, which includes an indication of the target entity. The payload section 600 includes a plurality of data fields: a version identification field 601, an IP version identification field 602, a port definition field 603, and an IP address specification field 604. The payload section 600 may further include a token field 605. The version identification field 601 provides an indication that the structure of the payload section 600 is as illustrated in FIG. 6. This structure can be considered as a particular version of payload section 600 among different possible versions. The IP version identification field 602 indicates a version that is used to specify an IP address of the target entity.
The port definition field 603 may use a 16-bit integer to define a destination port, in a manner that may be similar to that used to define the destination port in the header of a SYN segment. The IP address specification field 604 specifies the IP address of the target entity. The length of this field depends on the version used to specify the IP address. In other words, the length of the specification field of the IP address 604 can be deduced from the version indicated in the identification field of the IP version 602. The token field 605, which may be optional, may specify a identification token that can be used to authenticate the data transfer connection to be established. For example, the identification token may be generated based on a shared secret between entities involved in establishing the data transfer connection, such as, for example, the intermediate device 103 shown in FIG. 2.
An indirect connection request as described above may be used in applications other than multipath connections. The indirect connection request generally allows an intermediate device to be explicit during a data transfer connection. In other words, two entities between which the data transfer connection extends are aware, so to speak, of the presence of the intermediate device in this connection. This can solve problems caused, for example, by bad interactions between devices present in a data transfer connection.
Remarks
The above detailed description with reference to the drawings is only an illustration of the invention and additional features, which are defined in the claims. The invention can be realized in many different ways. In order to illustrate this, some alternatives are indicated briefly. The invention can be advantageously applied in many types of methods or products relating to data transfer according to a protocol. The transfer of data does not necessarily imply the use of the Internet as described above as an example. Data transfer may involve other types of communication networks. Also, the protocol need not be TCP with its MPTCP multipath extension as described above as an example. The protocol can in principle be any protocol with an extension. In addition, the extension of the protocol does not have to be a multipath extension.
An intermediate device can determine many different ways if a targeted device is capable of handling multipath extension. The intermediate device does not necessarily need to systematically issue a connection request to the targeted device. For example, the intermediate device may store information indicating whether or not the targeted device is capable of handling the multipath extension. This information can be obtained by analyzing an acknowledgment received in response to a connection request as described above. The intermediate device can then store the information thus obtained for use in a subsequent determination. In another example, information as to whether a particular device is capable of handling multiple paths can be obtained from another device that collects such information. Such information may be broadcast through a communication network to which the intermediate device belongs.
The term "device" in the broad sense should always be understood. The term can encompass any entity that can send data, or receive data, or both.
The term "address" in the broad sense should always be understood. The term may encompass any type of indication that may designate a destination entity. For example, the term may include an IPv4 address, an IPv6 address, a destination port, or a mixture thereof.
There are generally many different ways of implementing the invention, insofar as different implementations may have different topologies. In any given topology, a single module can perform several functions, or several modules can collectively perform a single function. In this respect, the drawings are very schematic. Many functions can be implemented using hardware or software, or a combination of both. A software implementation description does not exclude a hardware implementation, and vice versa. Hybrid implementations, which include one or more dedicated circuits as well as one or more processors programmed accordingly, are also possible. For example, several functions described above with reference to the figures can be implemented by means of one or more dedicated circuits, insofar as a particular circuit topology defines a particular function.
The foregoing remarks show that the detailed description with reference to the drawings illustrates the invention rather than limiting it. The invention can be implemented in many different ways that fall within the scope of the appended claims. Any changes that fall within the meaning and equivalence range of the claims must be encompassed within the scope of the claims. Any reference in a claim can not be interpreted as a limitation of the claim. The word "understand" or "include" does not exclude the presence of other elements or steps other than those listed in a claim. The word "a" or "an" preceding an element or a step does not exclude the presence of a plurality of such elements or steps. The mere fact that respective dependent claims define additional respective functionalities does not exclude additional functionality combinations other than those set out in the claims.

权利要求:
Claims (15)
[1]
CLAIMS:
A method of establishing a data transfer connection (301) between a device (101, 105) and another device (102) using a basic protocol with a multipath extension enabling the data transfer connection to use a plurality of different paths (304, 305) in parallel, the method involving an intermediate device (103) which performs: - a receiving step (203) in which the intermediate device receives a connection request (212) from the device, the connection request comprising: - an indication that the device is capable of handling the multipath extension; a destination field that specifies an address (113) of the intermediate device; a field (500, 600) other than the destination field which comprises an address (504, 604) of the other device with which the data transfer connection is to be established; a determination step (204, 206) in which the intermediate device determines whether the other device is capable of handling the multipath extension or not; a connection establishment step (207) in which the intermediate device establishes the data transfer connection according to the multipath extension if the other device is capable of managing the multipath extension and, in the case of contrary, wherein the intermediate device establishes the data transfer connection as a concatenation of two data transfer connection portions: - a multipath data transfer connection portion (302) between the device and the intermediate device according to multipath extension; and a base data transfer connection part (303) between the intermediate device and the other device according to the basic protocol.
[2]
A method of establishing a data transfer connection according to claim 1, wherein the determining step comprises two substeps: a substep of connection request transmission (204) in which the intermediate device transmits to the other device a subsequent connection request including an indication that the intermediate device is capable of managing the multipath extension; and an acknowledgment analysis substep (206) in which the intermediate device, upon receipt of an acknowledgment from the other device, determines whether the acknowledgment includes an indication that the other device is capable or not of managing the multipath extension.
[3]
A method of establishing a data transfer connection according to any one of claims 1 and 2, wherein, if the other device (102) is capable of managing the multipath extension, the intermediate device (103) performs: - a withdrawal step in which the intermediate device withdraws from the data transfer connection that has been established between the device and the other device.
[4]
A method of establishing a data transfer connection according to any one of claims 1 to 3, wherein the base protocol is a standardized protocol entitled Transmission Control Protocol (in French, transmission control protocol), commonly referred to by the acronym TCP, with a multipath extension called Multipath Transmission Control Protocol (in French, protocol of control of multipath transmission) commonly referred to by the acronym MPTCP.
[5]
A method of establishing a data transfer connection according to claim 4, wherein the connection request (212) comprises a SYN segment, the intermediate device (103) retrieving the identification (113) from the other device (102) to an option field (500) in a SYN segment header.
[6]
A method of establishing a data transfer connection according to claim 4, wherein the connection request (212) comprises a SYN segment, the intermediate device (103) retrieving the identification (113) from the other device (102) to a data field (604) in a payload section (600) of the SYN segment.
[7]
A method of establishing a data transfer connection according to any of claims 5 and 6, wherein the determining step comprises two substeps: a substep of transmission SYN (204) in wherein the intermediate device (103) transmits a SYN segment to the other device, the SYN segment having a header including an options field providing an indication that the intermediate device is capable of managing the path extension multiple; and a substep of SYN + ACK reception (206) in which the intermediate device, on receiving a SYN + ACK segment from the other device, determines whether the SYN + ACK has a header comprising an option field with an indication that the other device is capable of handling the multipath extension or not.
[8]
A method of establishing a data transfer connection according to any of claims 4 to 7, wherein, if the other device (102) is not capable of managing MPTCP, the intermediate device performs: a port provisioning step in which the intermediate device provides a MPTCP communication port for the multipath data transfer connection portion with the device, and wherein the intermediate device provides a TCP communication port for the portion of basic data transfer connection with the other device; a data relaying step in which payload data received at the MPTCP communication port is transferred to the TCP communication port, and vice versa.
[9]
A method of establishing a data transfer connection according to any one of claims 1 to 8, wherein the intermediate device (103) is a server in a network infrastructure.
[10]
A method of generating a connection request (212) enabling a device (101) to establish a data transfer connection (301) with another device (102) according to a protocol, which defines that the request for connection comprises a plurality of different fields, including a destination field that specifies an address to which the connection request is directed, the method comprising: - a target entity specification step in which a field (500, 600) of the request for connection (212) other than the destination field is provided with an address (113) of the other device; an intermediate device specification step in which the destination field is provided with an address (111) of an intermediate device (103) designed to extract from the connection request the address of the other device and to generate a subsequent connection request (213) which includes the address of the other device in the destination field.
[11]
A method of generating a connection request according to claim 10, wherein in the target entity specification step the field which is provided with the address (113) of the other device (102). is an option field (505) in a header of the connection request (212).
[12]
A method of generating a connection request according to claim 10, wherein in the target entity specifying step the field which is provided with the address (113) of the other device (102). is a data field (604) in a payload section (600) of the connection request (212).
[13]
The method of generating a connection request according to any one of claims 10 to 12, the method being performed on receipt of an initial connection request (211) from the device (101), the method comprising: a recovery step (202) in which the address (113) of the other device (102) is retrieved from the destination field in the initial connection request in order to place this address in the field (500, 600) of the connection request (212) other than the destination field.
[14]
A computer program comprising a set of instructions that allows a processor, capable of executing the instruction set, to implement the method of any one of claims 1 to 13.
[15]
Processor designed to carry out the method according to any one of claims 1 to 13.

类似技术:

公开号 | 公开日 | 专利标题

BE1022510B1|2016-05-17|Establish a data transfer connection

CN107852604B|2021-12-03|System for providing Global Virtual Network |

US9647871B2|2017-05-09|Routing proxy for resource requests and resources

US20140250204A1|2014-09-04|Virtual channel joining

EP3284224B1|2020-02-12|Method for emulating a multipath connection

US8817815B2|2014-08-26|Traffic optimization over network link

FR3053197A1|2017-12-29|METHOD FOR UDP COMMUNICATION VIA MULTIPLE PATHS BETWEEN TWO TERMINALS

EP3210346B1|2018-12-12|Method of creating a substream of data packets

WO2019002754A1|2019-01-03|Method of quic communication via multiple paths

EP3476096B1|2020-08-26|Udp communication method between two terminals via multiple paths

CN110024329B|2021-01-29|Service function chain and overlay transport loop prevention

EP3318023B1|2020-06-17|Method of optimizing the loading of a network connections hub

EP2997717A1|2016-03-23|Method and device for selecting a communication interface

WO2013167745A1|2013-11-14|Data transmission system

FR3075530A1|2019-06-21|METHOD FOR OPTIMIZING SPECTRAL EFFICIENCY IN AN MPLS INTERCONNECTION CONTEXT

EP2399406B1|2017-12-20|Method for switching an access node

FR3044195A1|2017-05-26|METHOD AND DEVICE FOR PROCESSING A NON-LEGITIMATE ANNOUNCEMENT OF AN IP ADDRESS BLOCK

WO2020260813A1|2020-12-30|Method for managing communication between terminals in a communication network, and devices for implementing the method

FR3081645A1|2019-11-29|COMMUNICATION METHOD IMPLEMENTED BY A FIRST ROUTER OF AN AUTONOMOUS SYSTEM USING AN INTERNAL ROUTING PROTOCOL

WO2020120850A1|2020-06-18|Terminal that can be connected simultaneously to multiple access networks, method for differentiating traffic emitted by the terminal, device and method for managing the traffic

同族专利:

公开号 | 公开日

US10110641B2|2018-10-23|

WO2015086543A1|2015-06-18|

EP3080957B1|2019-02-20|

US20160315976A1|2016-10-27|

EP2882148A1|2015-06-10|

EP3080957A1|2016-10-19|

AU2014363687A1|2016-06-02|

AU2014363687B2|2019-01-31|

引用文献:

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

US8473620B2|2003-04-14|2013-06-25|Riverbed Technology, Inc.|Interception of a cloud-based communication connection|

US7650416B2|2003-08-12|2010-01-19|Riverbed Technology|Content delivery for client-server protocols with user affinities using connection end-point proxies|

US7664032B2|2003-11-10|2010-02-16|Oki Electric Industry Co., Ltd.|Communication terminal and communication network|

US7633955B1|2004-02-13|2009-12-15|Habanero Holdings, Inc.|SCSI transport for fabric-backplane enterprise servers|

US20140304291A9|2006-05-24|2014-10-09|Sizhe Tan|Computer method for searching document and recognizing concept with controlled tolerance|

US8737409B2|2009-10-02|2014-05-27|Qualcomm Incorporated|Multipath communications for mobile node interfaces|

US8400923B2|2010-10-15|2013-03-19|Telefonaktiebolaget L M Ericsson |Multipath transmission control protocol proxy|

US9503223B2|2011-03-04|2016-11-22|Blackberry Limited|Controlling network device behavior|

US20120331160A1|2011-06-22|2012-12-27|Telefonaktiebolaget L M Ericsson |Multi-path transmission control protocol proxy service|

US9374337B2|2012-06-15|2016-06-21|Citrix Systems, Inc.|Systems and methods for supporting IP ownership in a cluster|AU2011380909A1|2011-11-10|2014-06-05|Adaptive Spectrum And Signal Alignment, Inc.|Method, apparatus, and system for optimizing performance of a communication unit by a remote server|

LT2789134T|2011-12-05|2019-06-25|Assia Spe, Llc|Systems and methods for traffic aggregation on multiple wan backhauls and multiple distinct lan networks|

US10362148B2|2014-01-27|2019-07-23|International Business Machines Corporation|Path selection using TCP handshake in a multipath environment|

GB2523394B|2014-02-25|2020-10-28|Mclaren Applied Tech Ltd|Vehicle data communication|

US9578109B2|2014-05-30|2017-02-21|Apple Inc.|Long-lived MPTCP sessions|

EP3163830B1|2014-07-21|2018-09-19|Huawei Technologies Co., Ltd.|Link control node, link control method and medium|

CN112491623A|2014-12-04|2021-03-12|适应性频谱和信号校正股份有限公司|Method and apparatus for predicting successful DSL line optimization|

US9813465B2|2014-12-19|2017-11-07|Intel Corporation|Network proxy for energy efficient video streaming on mobile devices|

US10397379B2|2015-03-06|2019-08-27|Apple Inc.|Robust multipath TCP stateless connection establishment|

FR3038475A1|2015-07-01|2017-01-06|Orange|METHOD FOR OPTIMIZING THE LOAD OF A NETWORK CONNECTION CONCENTRATOR|

US10476980B2|2015-08-07|2019-11-12|Dell Products L.P.|Remote socket splicing system|

CN106612211B|2015-10-23|2020-02-21|华为技术有限公司|Path detection method, controller and network equipment in VxLAN|

EP3255845A1|2016-06-10|2017-12-13|Tessares SA|Multipath tcp in hybrid access networks|

EP3484830A1|2016-07-18|2019-05-22|Ecole Polytechnique Federale de Lausanne |Hardening acceleration/hardening retardation composition for building materials|

EP3276891B1|2016-07-29|2019-02-27|Deutsche Telekom AG|Techniques for establishing a communication connection between two network entities via different network flows|

US10257283B2|2016-10-03|2019-04-09|International Business Machines Corporation|System, method and computer program product for network function modification|

CN109120540B|2017-06-23|2021-09-14|华为技术有限公司|Method for transmitting message, proxy server and computer readable storage medium|

WO2019166697A1|2018-03-01|2019-09-06|Nokia Technologies Oy|Conversion between transmission control protocols|

EP3614794A1|2018-08-22|2020-02-26|Tessares SA|Multi-path access network|

CN109587275A|2019-01-08|2019-04-05|网宿科技股份有限公司|A kind of method for building up and proxy server of communication connection|

US10659569B1|2019-01-18|2020-05-19|Hewlett Packard Enterprise Development Lp|End-to-end multipath TCP through network gateways|

EP3923533A1|2020-06-09|2021-12-15|Tessares SA|Multipath proxy|

法律状态:

优先权:

申请号 | 申请日 | 专利标题

EP13196340|2013-12-09|

EP13196340.7A|EP2882148A1|2013-12-09|2013-12-09|Establishing a data transfer connection|

[返回顶部]